![[アップデート] VPC からのアウトバウンド DNS クエリをフィルタリング。Amazon Route 53 Resolver DNS Firewall がリリースされました。](https://devio2023-media.developers.io/wp-content/uploads/2019/05/amazon-route-53.png)
[アップデート] VPC からのアウトバウンド DNS クエリをフィルタリング。Amazon Route 53 Resolver DNS Firewall がリリースされました。
本日のアップデートで Route 53 Resolver に新たな機能として DNS Firewall が追加されました。
DNS Firewall?
DNS Firewall は VPC からのアウトバウンド DNS リクエストを保護します。保護方法の例としては以下のとおりです。
- 特定のドメイン名以外の名前解決をさせない
- 不良と判別されているドメイン名の名前解決をさせない
これらの方法により、DNS の侵害やマルウェア感染により、ユーザーの知らないところで悪意のあるサイトへ誘導されるような攻撃から保護することが可能になりました。
管理方法
DNS FIrewall は AWS Firewall Manager を使用して AWS Organization 内のアカウント全体で一元的に設定、管理することができます。また、AWS Organization を利用していない場合でも、VPC 単位で DNS Firewall ルールグループを関連付けて保護することが可能です。
AWS Network Firewall と何が違うの？
ドメイン名でのアウトバウンドを保護するという点でいうと、最近、東京リージョンでも GA された AWS Network Firewall が思い浮かびます。AWS Network Firewall でもドメイン名を指定したフィルタリングは可能ですが、何が違うのでしょうか？
ざっくり言えば、トラフィックをフィルタする場所が違います。
- DNS Firewall : VPC から Route 53 Resolver を通過するアウトバウンド DNS クエリをフィルタします
- AWS Network Firewall : ネットワーク層とアプリケーション層のトラフィックをフィルタします
解りやすく図にすると、このような感じになるかと思います。
このように保護する対象が異なりますので、どちらか一方を選べば良いというものではありません。
例えば /etc/hosts そのものに悪意のあるサイトへ誘導するように書き換えられてしまった場合、これは DNS Firewall では保護することが出来ませんので AWS Network Firewall などネットワーク層、アプリケーション層での保護が必要となります。
料金
料金は「ルールに追加するドメインの数」と「クエリ回数」の２パターンです。
- ルールに登録されたドメインの数あたり $ 0.0005/月
- 処理されたクエリ 100 万回あたり $ 0.60
詳細は公式の価格表を参照ください。
対応リージョン
執筆時点で対応しているリージョンは以下の 4 リージョン。残念ながら東京リージョンはまだ利用できません。
- バージニア北部
- オレゴン
- アイルランド
- ムンバイ
2020.04.08 追記 すべてのリージョンで利用可能になりました。・Amazon Route 53 Resolver DNS Firewall Generally Available
やってみる
それでは早速ためしてみましょう。今回はバージニアリージョンで検証しています。
DNS Firewall の作成
VPC 管理コンソールから [DNS Firewall] - [Rule Groups] を開き、[Create rule group] をクリックします。任意のルールグループ名を指定して [Next] をクリック。
現状、何もルールがないので [Add rule] をクリックしてルールを作成します。任意のルール名を入力します。
次に [Domain list] で以下 2 つのタイプのいずれかを選択します。
AWS で管理されたドメインリスト Add AWS managed domain list の場合は 2 つのリストからいずれかを選択します。
- Add AWS managed domain list
- AWSManagedDomainsMalwareDomainList : スパムマルウェアに感染したコンピューターのネットワークの制御に関連することが知られているドメイン
- AWSManagedDomainsBotnetCommandandControl : スパムマルウェアに感染したコンピューターのネットワークを制御することが知られているドメイン
- Add my own domain list
今回は Add my own domain list を選択し、ユーザー側でリストを作成します。Create new domain listを選択し任意のリスト名を入力します。
あらかじめリストを作成し S3 から読み込む場合は Switch to bulk upload を使用しますが、今回は直書きで dev.classmethod.jp としました。*.classmethod.jp のように * で始めることもできます。
次にアクションですが、一旦、ALERT で検証しましょう。本番環境など既にサービスが動いている VPC に適用する場合はいきなり BLOCK すると障害を引き起こし兼ねません。
まずは ALERT に設定したうえで Route 53 Resolver の DNS クエリログなどで意図した判定になること確認するのが吉です。 [Add rule] をクリックしてルールを追加します。
[Add rule] できたことを確認して [Next] をクリック。
次に優先順位の指定です。複数のルールがある場合は、ここで適用される優先順位を指定します。Priority の値が小さいものから順に適用されます。今回は 1 つしかないので、そのまま [Next] をクリック。
タグの設定などは今回スルーして Create rule group まで実行します。作成直後の状態は、まだ何処にも関連付けしていないので VPC association status は Not Associated のままになっています。
VPC 関連付け
作成したばかりのルールグループを選択し、下段画面から [Associated VPCs] タブを開き、Associate VPC をクリックします。
関連付けする VPC を選択し [Associate] します。
しばらくすると VPC association status が Associated に変わりますので、これで準備は完了です。
ALERT 通知の検証
ルールグループを関連付けした VPC 内の EC2 から DNS クエリが実行されるようなコマンドを実行します。今回は dig と curl でテストしてみましょう。
$ curl -I https://dev.classmethod.jp/ HTTP/2 200 date: Thu, 01 Apr 2021 10:49:58 GMT content-type: text/html; charset=utf-8 content-length: 167035 （後略） $ dig dev.classmethod.jp +short 99.83.185.173 75.2.71.201
ルールのアクションは ALERT ですので正常に動作しますが、DNS クエリログを確認すると、以下のとおり firewall_rule_action が ALERT で判定されていることが解ります。
{
"version": "1.100000",
"account_id": "XXXXXXXXXXXX",
"region": "us-east-1",
"vpc_id": "vpc-XXXXXXX",
"query_timestamp": "2021-04-01T11:21:13Z",
"query_name": "dev.classmethod.jp.",
"query_type": "AAAA",
"query_class": "IN",
"rcode": "NOERROR",
"answers": [
{
"Rdata": "2406:da14:d37:ef11:dc0d:a4e5:5c74:c1c2",
"Type": "AAAA",
"Class": "IN"
},
{
"Rdata": "2406:da14:d37:ef12:fc54:e42f:a1b0:18ea",
"Type": "AAAA",
"Class": "IN"
},
{
"Rdata": "2406:da14:d37:ef13:a651:dfb4:e258:4d22",
"Type": "AAAA",
"Class": "IN"
}
],
"srcaddr": "172.31.16.198",
"srcport": "52162",
"transport": "UDP",
"srcids": {
"instance": "i-0fc176756e95a758d"
},
"firewall_rule_action": "ALERT",
"firewall_rule_group_id": "rslvr-frg-1aa5d78b60714ba7",
"firewall_domain_list_id": "rslvr-fdl-c5d9cceb40024f74"
}
ちなみにリストに記載していない正常なリクエストの場合、以下のようなログになります。
{
"version": "1.100000",
"account_id": "XXXXXXXXXXXX",
"region": "us-east-1",
"vpc_id": "vpc-XXXXXXXX",
"query_timestamp": "2021-04-01T11:29:09Z",
"query_name": "classmethod.jp.",
"query_type": "A",
"query_class": "IN",
"rcode": "NOERROR",
"answers": [
{
"Rdata": "13.32.207.5",
"Type": "A",
"Class": "IN"
},
{
"Rdata": "13.32.207.66",
"Type": "A",
"Class": "IN"
},
{
"Rdata": "13.32.207.69",
"Type": "A",
"Class": "IN"
},
{
"Rdata": "13.32.207.27",
"Type": "A",
"Class": "IN"
}
],
"srcaddr": "172.31.16.198",
"srcport": "47915",
"transport": "UDP",
"srcids": {
"instance": "i-0fc176756e95a758d"
}
}
ルールを変更して再検証
次にルールを BLOCK に変更してみましょう。
該当の DNS Firewall ルールの編集画面を開き、アクションを BLOCK に指定します。ブロック時のレスポンスタイプは 3 タイプのいずれかを指定します。今回は NODATA を指定して
Save rule します。
- NODATA
- このクエリは成功しましたが、クエリに対して利用可能な応答がないことを示します
- NXDOMAIN
- クエリに含まれるドメイン名が存在しないことを示します
- OVERRIDE
- クエリに対するカスタムオーバーライドレスポンスを提供します
それではあらためて、同じコマンドを実行してみましょう。DNS レコードの TTL が切れるまで応答が返ってきますので、その場合は TTL が切れるまで待ってからテストしてください。
$ curl -I https://dev.classmethod.jp/ curl: (6) Could not resolve host: dev.classmethod.jp $ dig dev.classmethod.jp ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.4 <<>> dev.classmethod.jp ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2351 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;dev.classmethod.jp. IN A ;; Query time: 3 msec ;; SERVER: 172.31.0.2#53(172.31.0.2) ;; WHEN: 木 4月 01 10:57:30 UTC 2021 ;; MSG SIZE rcvd: 47
先ほどと違って名前解決による IP アドレスが引けておらず、アクセス出来なくなりましたね。もちろんブロックされているのはリストに記載した dev.classmethod.jp だけですので、その他のドメインは問題ありません。
$ dig classmethod.jp +short 13.32.207.66 13.32.207.69 13.32.207.5 13.32.207.27
DNS クエリログを参照すると、以下のように BLOCK されたことが解ります。
{
"version": "1.100000",
"account_id": "XXXXXXXXXXXX",
"region": "us-east-1",
"vpc_id": "vpc-XXXXXXX",
"query_timestamp": "2021-04-01T12:48:16Z",
"query_name": "dev.classmethod.jp.",
"query_type": "AAAA",
"query_class": "IN",
"rcode": "NOERROR",
"answers": [],
"srcaddr": "172.31.16.198",
"srcport": "57822",
"transport": "UDP",
"srcids": {
"instance": "i-0fc176756e95a758d"
},
"firewall_rule_action": "BLOCK",
"firewall_rule_group_id": "rslvr-frg-1aa5d78b60714ba7",
"firewall_domain_list_id": "rslvr-fdl-c5d9cceb40024f74"
}
検証は以上です！
まとめ
- DNS Firewall は VPC からの DNS アウトバウンドクエリを保護する機能
- AWS Network Firewall はネットワーク層、アプリケーション層のトラフィックをフィルタするのに対し、DNS Firewall は DNS クエリをフィルタする。役割が違うので、どちらか一方を選べば良いというものではない
- ドメインリストはカスタムすることも出来るし、AWS マネージドなリストを使うことも可能
- AWS Firewall Manager を使うことで AWS Organization で一元管理することが可能。AWS アカウントごとに VPC に個別に関連付けることも可能
- 東京リージョンではまだ使えない
